home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-hares-idrp-05.txt < prev    next >
Text File  |  1993-10-13  |  43KB  |  1,192 lines
  1.  
  2. Network Working Group                                 Susan Hares
  3. INTERNET DRAFT                                       Merit/NSFNET
  4. <draft-hares-idrp-05.txt>                            John Scudder
  5.                                                      Merit/NSFNET
  6.                                                    September 1993
  7.  
  8.  
  9.  
  10.  
  11.                               IDRP for IP
  12.  
  13.  
  14. Status of this memo
  15.  
  16.  
  17.    This memo specifies the adaptation of the ISO Inter-Domain Routing
  18.    Protocol ([1]) that enables it to be used as an Inter-Autonomous
  19.    System routing protocol in the TCP/IP Internet.  IDRP with this
  20.    adaptation will be called "IDRP for IP" in this document.  Dual IDRP,
  21.    that is, a single instance of IDRP that can simultaneously support
  22.    Inter-Domain/Inter-Autonomous System routing in the TCP/IP and OSI
  23.    Internets is outside the scope of this document.
  24.  
  25.    This document is an Internet Draft. Internet Drafts are working
  26.    documents of the Internet Engineering Task Force (IETF), its Areas,
  27.    and its Working Groups. Note that other groups may also distribute
  28.    working documents as Internet Drafts.
  29.  
  30.    Internet Drafts are draft documents valid for a maximum of six
  31.    months. Internet Drafts may be updated, replaced, or obsoleted by
  32.    other documents at any time. It is not appropriate to use Internet
  33.    Drafts as reference material or to cite them other than as a "working
  34.    draft" or "work in progress."
  35.  
  36.  
  37.  
  38. 1. Overview
  39.  
  40.  
  41.    IDRP ([1]) is defined as the protocol for exchange of Inter-Domain
  42.    routing information between routers to support forwarding of ISO 8473
  43.    (Connectionless Network Layer Protocol (CLNP))[2] PDUs.
  44.  
  45.    The network reachability information exchanged via IDRP provides
  46.    sufficient information to detect routing loops and enforce routing
  47.    decisions based on performance preference and policy constraints as
  48.    outlined in RFC 1104 [9]. In particular, IDRP exchanges routing
  49.    information containing full domain-level paths and enforces routing
  50.    policies based on configuration information.
  51.  
  52.    As the Internet has evolved and grown over in recent years, it has
  53.    become evident that it is soon to face several serious scaling
  54.    problems. These include:
  55.  
  56.    Exhaustion of the class B network address space. One fundamental
  57.  
  58.  
  59. Expiration Date February 1994                           [Page 1]
  60.  
  61.  
  62.  
  63.  
  64. INTERNET DRAFT                                           September 1993
  65.  
  66.  
  67.    cause of this problem is the lack of a network class of a size which
  68.    is appropriate for mid-sized organization; class C, with a maximum of
  69.    254 host addresses, is too small while class B, which allows up to
  70.    65534 addresses, is too large to be densely populated.  Growth of
  71.    routing tables in Internet routers are beyond the ability of current
  72.    software (and people) to effectively manage.  Eventual exhaustion of
  73.    the 32-bit IP address space.
  74.  
  75.    It has become clear that the first two of these problems are likely
  76.    to become critical within the next one to three years.  Classless
  77.    inter-domain routing (CIDR) [7], [10] attempts to deal with these
  78.    problems by proposing a mechanism to slow the growth of the routing
  79.    table and the need for allocating new IP network numbers. It does not
  80.    attempt to solve the third problem, which is of a more long-term
  81.    nature, but instead endeavors to ease enough of the short to mid-term
  82.    difficulties to allow the Internet to continue to function
  83.    efficiently while progress is made on a longer- term solution.
  84.  
  85.    IDRP may be viewed as an extension of BGP-4 [11] that provides (among
  86.    other things) much better scaling with respect to support for routing
  87.    information aggregation and reduction based on CIDR, as well as
  88.    stronger capabilities for policy based routing (e.g. ability to
  89.    impose control over transit traffic).
  90.  
  91.    This document specifies the appropriate adaptation of the IDRP
  92.    protocol definition that enables it to be used as a protocol for the
  93.    exchange of inter-autonomous system information among routers to
  94.    support the forwarding of IP packets across multiple autonomous
  95.    systems.
  96.  
  97.    The adaptation is defined is such a way that a Dual IDRP will be able
  98.    to fully interoperate with IDRP for IP.
  99.  
  100.  
  101. 2. Terminology
  102.  
  103.  
  104.    This document assumes that the reader is familiar with the following
  105.    documents:
  106.  
  107.    IP protocol specification (RFC 791)[5], and IDRP specification (IS
  108.    10747).
  109.  
  110.    A few definitions are in order to aid the reader:
  111.  
  112.       BIS - a Boundary Intermediate System (or border router)
  113.  
  114.       BISPDU - an IDRP message exchanged between a pair of BISs
  115.  
  116.       FIB - Forwarding Information Base (IP forwarding table)
  117.  
  118.       IS - Intermediate System (router)
  119.  
  120.       NET - Network Entity Title - an ISO network address for a router
  121.  
  122.  
  123. Expiration Date February 1994                           [Page 2]
  124.  
  125.  
  126.  
  127.  
  128.  
  129. INTERNET DRAFT                                           September 1993
  130.  
  131.  
  132.       NLRI - Network Layer Reachability Information (set of reachable
  133.       destinations)
  134.  
  135.       NPDU - an IP packet
  136.  
  137.       PDU - a packet
  138.  
  139.       SNPA - subnetwork point of attachment (MAC address)
  140.  
  141.  
  142. 3. Assumptions
  143.  
  144.  
  145.    The IDRP for IP protocol assumes that within a single connected
  146.    internet network addresses are unique.  The IDRP for IP protocol
  147.    cannot be guaranteed to work in an environment where network
  148.    addresses within a single connected internet are not unique.
  149.  
  150.    All of the discussions in this document are based on the assumption
  151.    that the Internet is a collection of arbitrarily connected Autonomous
  152.    Systems. That is, the Internet will be modeled as a general graph
  153.    whose nodes are AS's and whose edges are connections between pairs of
  154.    AS's.
  155.  
  156.    The classic definition of an Autonomous System is a set of routers
  157.    under a single technical administration, using an interior gateway
  158.    protocol and common metrics to route packets within the AS and using
  159.    an exterior gateway protocol to route packets to other AS's. Since
  160.    this classic definition was developed, it has become common for a
  161.    single AS to use several interior gateway protocols and sometimes
  162.    several sets of metrics within an AS. The use of the term Autonomous
  163.    System here stresses the fact that, even when multiple IGPs and
  164.    metrics are used, the administration of an AS appears to other AS's
  165.    to have a single coherent interior routing plan and presents a
  166.    consistent picture of which networks are reachable through it.
  167.  
  168.    AS's are assumed to be administered by a single administrative
  169.    entity, at least for the purposes of representation of routing
  170.    information to systems outside of the AS.
  171.  
  172.  
  173. 4. The Adaptation Layer
  174.  
  175.  
  176.    The Inter-Domain Routing Protocol (IDRP) or, more formally,
  177.  
  178.       "The Protocol for the Exchange of Inter-Domain Routeing
  179.       information among Intermediate Systems to support Forwarding of
  180.       ISO 8473 PDUs (IDRP)"
  181.  
  182.    is the inter-domain routing protocol defined to support the
  183.    forwarding of Connectionless Network Layer Protocol (CLNP) [ISO 8473]
  184.    packets that traverse multiple routing domains.
  185.  
  186.  
  187. Expiration Date February 1994                           [Page 3]
  188.  
  189.  
  190.  
  191. INTERNET DRAFT                                           September 1993
  192.  
  193.  
  194.    While this protocol was developed within ISO, it makes few, if any,
  195.    ISO-specific assumptions. In particular, it does not require
  196.    participating domains to support any specific ISO Intra-Domain
  197.    protocol, such as IS-IS (ISO IS 10589)[3], nor does it require
  198.    participating routers to run ES-IS (ISO 9542) [4].  The only
  199.    requirements imposed by the protocol on the participating routers is
  200.    that the protocol information can be exchanged between them over a
  201.    connectionless network layer, which in the case of OSI is CLNP, and
  202.    that the network layer connectivity between routers within a single
  203.    routing domain should be provided by means outside of IDRP (e.g., via
  204.    some intra-domain routing protocol).  IDRP does not place any
  205.    restrictions on the structure of reachability information, as long it
  206.    can be expressed as an arbitrary set of variable length address
  207.    prefixes.
  208.  
  209.    Since IP can provide connectionless service between routers, and
  210.    since reachable IP destinations can be expressed as IP address
  211.    prefixes, IDRP can be easily adapted to be an Inter-Autonomous System
  212.    routing protocol which can be used in the pure TCP/IP Internet.
  213.  
  214.    While conceptually it is possible to define a mapping between the
  215.    security field of an IP header and IDRP NPDU-derived distinguishing
  216.    attributes, this mapping is outside the scope of this document. In
  217.    addition, address-specific QoSs (Source Specific QoS and Destination
  218.    Specific QoS) have no counterparts in IP. Therefore, the use of the
  219.    following IDRP distinguishing attributes for IP packets will not be
  220.    defined in this document: Priority Locally Defined QoS Security
  221.  
  222.    Mapping between the following IDRP distinguishing attributes: Transit
  223.    Delay Residual Error Expense
  224.  
  225.    and the IP Type of Service (TOS) parameters is defined in Section
  226.    5.2.3 of this document.
  227.  
  228.    Note that an implementation that does not support any of the NPDU-
  229.    derived distinguishing attributes can fully interoperate with an
  230.    implementation that does support them. Therefore, an IDRP for IP
  231.    implementation that will support routing sensitive to the parameters
  232.    present in the TOS field of the IP header will be compatible with the
  233.    implementation that does not provide such support.
  234.  
  235.  
  236. 5. Implementor's Guide for IP specific functions.
  237.  
  238.  
  239.    In order to implement IDRP for IP, only a subset of the features of
  240.    the IDRP protocol must be implemented.
  241.  
  242.  
  243. 5.1 Features in IDRP which need not be implemented
  244.  
  245.  
  246.    The functions of the IDRP protocol which shall not be implemented for
  247.    IDRP for IP are those functions which deal with the following (all
  248.  
  249.  
  250. Expiration Date February 1994                           [Page 4]
  251.  
  252.  
  253.  
  254. INTERNET DRAFT                                           September 1993
  255.  
  256.  
  257.    references are with respect to the IDRP document [1]):
  258.  
  259.    Locally Defined QoS according to section 7.12.11 Security according
  260.    to section 7.12.14 Priority according to section 7.12.16 Forwarding
  261.    CLNP packets according to section 8 The interface to CLNP according
  262.    to section 9 support of the Network Management information described
  263.    in the IDRP GDMO according to section 11
  264.  
  265.    Therefore, with IDRP for IP the following items dealing with CLNP in
  266.    the IDRP conformance clause (section 12.1 of [1]) shall not be
  267.    implemented:
  268.  
  269.    clause (d): Locally Defined QoS, Security, Priority clause (r) clause
  270.    (s) clause (t)
  271.  
  272.  
  273. 5.1.1 PICS Table Information
  274.  
  275.  
  276.    The PICS (Protocol Implementation Conformance Statement) provides a
  277.    convenient and concise mechanism to define which functions need and
  278.    need not be implemented for IDRP for IP.  All references in this
  279.    section are with respect to [1].  All items with PICS Status as
  280.    Optional need not be implemented in IDRP for IP.  Specifically, IDRP
  281.    for IP does not require support for the following items:
  282.  
  283.       A.4.3 Table 9:
  284.          MGT
  285.  
  286.       A.4.8 (Table 14):
  287.          PSRCRT, DATTS, MATCH
  288.  
  289.       A.4.11 (Table 17):
  290.          LQOSG, SECG, PRTY
  291.  
  292.       A.4.11 (Table 18):
  293.          LQOSP, SECP, PRTYP
  294.  
  295.       A.4.11 (Table 19):
  296.          LQOSR, SECR, PRTYR
  297.  
  298.  
  299.    Implementation of all other items with Optional Status not listed in
  300.    the previous paragraph is optional.
  301.  
  302.  
  303. 5.2 Features in IDRP which shall be implemented
  304.  
  305.  
  306.    An implementation of IDRP for IP shall contain all mandatory features
  307.    of IDRP, except those mentioned in Section 5.1 of this document. In
  308.    addition, a BIS for IDRP for IP shall implement:
  309.  
  310.    an interface to the IP protocol described in section 5.2.1 of this
  311.  
  312.  
  313. Expiration Date February 1994                           [Page 5]
  314.  
  315.  
  316. INTERNET DRAFT                                           September 1993
  317.  
  318.  
  319.    document the ability to identify and extract IP reachability and IP
  320.    forwarding information as described in section 5.2.2 of this document
  321.    IP packet forwarding functions described in section 5.2.9 of this
  322.    document domain configuration information listed in section 5.2.8 of
  323.    this document the advertisement of IP address information in NLRI as
  324.    described in section 5.3 of this document
  325.  
  326.  
  327.  
  328. 5.2.1 Exchanging IDRP information between IP-only routers.
  329.  
  330.  
  331.    IDRP assumes pair-wise communication between participating BISs.
  332.    IDRP information is carried between a pair of BISs in the form of
  333.    BISPDUs.  In the case of IDRP for IP, these BISPDUs are carried in
  334.    the data field of IP packets of protocol type 45.
  335.  
  336.  
  337. 5.2.2 Identifying IP reachability and IP forwarding information
  338.  
  339.  
  340.    NLRI passed by the UPDATE PDU has an indication of protocol type.  An
  341.    implementation of IDRP for IP shall have the following values in the
  342.    NLRI field:
  343.  
  344.       Proto_Type: 1 (ISO/IEC TR 9577 IPI/SPI)
  345.  
  346.       Proto_Length: 1
  347.  
  348.       Protocol:  hexadecimal 'CC'
  349.  
  350.       Addr_Length: variable (the value shall be between 4 and 32)
  351.  
  352.       Addr_Info: IP address prefixes, encoded in binary, as follows:
  353.  
  354.          This is a variable length field that contains a list of IP
  355.          address prefixes for the routes that are being advertised.
  356.          Each IP address prefix is encoded as a 2-tuple of the form
  357.          <length, prefix>, whose fields are described below:
  358.  
  359.  
  360.                           +---------------------------+
  361.                           |   Length (1 octet)        |
  362.                           +---------------------------+
  363.                           |   Prefix (variable)       |
  364.                           +---------------------------+
  365.  
  366.  
  367.  
  368.          The use and the meaning of these fields are as follows:
  369.  
  370.          a) Length:
  371.  
  372.             The Length field indicates the length in bits of the IP
  373.  
  374.  
  375. Expiration Date February 1994                           [Page 6]
  376.  
  377.  
  378.  
  379. INTERNET DRAFT                                           September 1993
  380.  
  381.  
  382.             address prefix. A length of zero indicates a prefix that
  383.             matches all IP addresses (with prefix, itself, of zero
  384.             octets).
  385.  
  386.          b) Prefix:
  387.  
  388.             The Prefix field contains IP address prefixes followed by
  389.             enough trailing bits to make the end of the field fall on an
  390.             octet boundary. Note that the value of trailing bits is
  391.             irrelevant.
  392.  
  393.  
  394.    An implementation of IDRP for IP shall ignore any NLRI indicating a
  395.    different protocol type.
  396.  
  397.    The NEXT_HOP attribute in the UPDATE PDU also has a Type field which
  398.    indicates the protocol family for the address of the NEXT_HOP. An
  399.    implementation of IDRP for IP shall have the following values in the
  400.    NEXT_HOP field:
  401.  
  402.       Proto_Type: 1 (ISO/IEC TR 9577 IPI/SPI)
  403.  
  404.       Proto_Length: 1
  405.  
  406.       Protocol: hexadecimal 'CC'
  407.  
  408.       Length of NET: 4
  409.  
  410.       NET of Next Hop: an IP address, encoded in binary as specified in
  411.       section 5.2.2.
  412.  
  413.       SNPA information:  as appropriate for the subnetwork type in use
  414.  
  415.    An implementation of IDRP for IP shall ignore any NEXT_HOP
  416.    information indicating a different protocol type.
  417.  
  418.  
  419. 5.2.3 Mapping between IP Type Of Service parameters and IDRP
  420. distinguishing attributes.
  421.  
  422.  
  423.    IP defines four distinct Type of Service (TOS) Parameters (see [12]):
  424.    minimize delay maximize throughput maximize reliability minimize
  425.    monetary cost
  426.  
  427.    An IP packet can carry at most one of the above TOSs. Therefore, a
  428.    RIB in IDRP for IP can have at most one distinguishing attribute.
  429.  
  430.    IDRP for IP supports the following distinguishing attributes: Transit
  431.    Delay Residual Error Expense
  432.  
  433.    A conformant implementation is required to recognize these attributes
  434.    when received from an adjacent BIS.
  435.  
  436.  
  437. Expiration Date February 1994                           [Page 7]
  438.  
  439.  
  440.  
  441. INTERNET DRAFT                                           September 1993
  442.  
  443.  
  444.    An IP-derived distinguishing attribute is defined as the TOS
  445.    parameter extracted from an IP packet that needs to be forwarded by a
  446.    BIS.
  447.  
  448.    The mapping between the IP-derived distinguishing attribute and a
  449.    RIB-Att is defined as follows:
  450.  
  451.  
  452.          IP TOS                       IDRP distinguishing attribute
  453.  
  454.          ------                       -----------------------------
  455.  
  456.          minimize delay               Transit Delay
  457.  
  458.          maximize reliability         Residual Error
  459.  
  460.          minimize monetary cost       Expense
  461.  
  462.          maximize throughput          Default
  463.  
  464.  
  465.  
  466. 5.2.4 ATOMIC_AGGREGATE Attribute
  467.  
  468.  
  469.    A new optional transitive attribute, ATOMIC_AGGREGATE, is defined for
  470.    use in IDRP for IP.  This attribute is intended to facilitate
  471.    interoperation between IDRP for IP and BGP-4.  The type code of this
  472.    attribute shall be 129.   This attribute has a length of zero octets.
  473.  
  474.  
  475.    This attribute shall be handled as follows:
  476.  
  477.    Any IDRP for IP router receiving a route with the ATOMIC_AGGREGATE
  478.    attribute shall not deaggregate that route.
  479.  
  480. 5.2.5 AGGREGATE Attribute
  481.  
  482.  
  483.    A new optional transitive attribute, AGGREGATOR is defined for use in
  484.    IDRP for IP.  This attribute is intended to facilitate interoperation
  485.    between IDRP for IP and BGP-4.  The type code of this attribute shall
  486.    be 130.    This attribute shall have the following encoding:
  487.  
  488.  
  489.           proto_type - 1 octet
  490.  
  491.           proto_length - 1 octet
  492.  
  493.           protocol (variable)
  494.  
  495.           length of address in bytes - 1 octet
  496.  
  497.           aggregator's address
  498.  
  499.  
  500. Expiration Date February 1994                           [Page 8]
  501.  
  502.  
  503. INTERNET DRAFT                                           September 1993
  504.  
  505.  
  506.    For IP this encoding would be:
  507.  
  508.           proto_type: 1 (ISO/IEC TR 9577 IPI/SPI)
  509.  
  510.           proto_length: 1
  511.  
  512.           protocol: hexadeicmal 'CC'
  513.  
  514.           length of address: 4
  515.  
  516.           address: IP address
  517.  
  518.  
  519.    This attribute shall be handled as follows:
  520.  
  521.    An IDRP for IP speaker may add this attribute to indicate that it
  522.    performed aggregation.
  523.  
  524. 5.2.6 SDRP Attribute
  525.  
  526.  
  527.    A new optional transitive attribute, SDRP is defined for use in IDRP
  528.    for IP.  This attribute is intended to both facilitate interoperation
  529.    between IDRP for IP and BGP-4, and to allow SDRP speakers to be
  530.    identified in the network.  The type code of this attribute shall be
  531.    131.    This attribute shall have the following encoding for each
  532.    protocol family.  Multiple  protocol families may be included in the
  533.    attribute.
  534.  
  535.  
  536.           proto_type - 1 octet)
  537.  
  538.           proto_length (1 octet)
  539.  
  540.           protocol (variable)
  541.  
  542.           count of SDRP speakers - 2 octets
  543.  
  544.           addresses of SDRP speakers
  545.  
  546.           (The address information is specific to protocol.)
  547.  
  548.  
  549.    For IP Address, the format of the rest of the attribute is 4 byte
  550.    octets, just like BGP.
  551.  
  552.    For CLNP addresses, the format of the rest of the attribute is a set
  553.    of tuples with (length of NETs, NET) with the following format.
  554.  
  555.  
  556.    length of address of SDRP speaker - 1 octet
  557.  
  558.    address of SDRP speaker - (variable)
  559.  
  560.  
  561. Expiration Date February 1994                           [Page 9]
  562.  
  563.  
  564.  
  565. INTERNET DRAFT                                           September 1993
  566.  
  567.  
  568.    For IP this encoding would be:
  569.  
  570.           proto_type: 1 (ISO/IEC TR 9577 IPI/SPI)
  571.  
  572.           proto_length: 1
  573.  
  574.           protocol: hexadeicmal 'CC'
  575.  
  576.           count of SDRP speakers
  577.  
  578.           address: IP address list
  579.  
  580.  
  581.    This attribute shall be handled as follows:
  582.  
  583.    An IDRP for IP speaker may add this attribute to if it is an SDRP
  584.    speaker for the domain.  It may add its own address and other SDRP
  585.    speaker for the domain.
  586.  
  587. 5.2.7 Confederations of Autonomous Systems.
  588.  
  589.  
  590.    IDRP supports the ability to group Routing Domains into a Routing
  591.    Domain Confederation.  Likewise, IDRP for IP supports the ability to
  592.    group a collection of Autonomous Systems into a Confederation of
  593.    Autonomous Systems.  With respect to the IDRP document in the context
  594.    of IDRP for IP, the terms "Routing Domain Confederation" and
  595.    "Confederation of Autonomous Systems" should be treated as
  596.    synonymous.
  597.  
  598.  
  599. 5.2.8  Domain Configuration Information
  600.  
  601.  
  602.    Correct Operation of IDRP described in [1] assumes that a minimum
  603.    amount of information is available to both the inter-domain and
  604.    intra-domain routing protocols. This information is static in nature,
  605.    and is not expected to change frequently.  This document assumes that
  606.    this information is supplied via IDRP MIB ([6]). While the following
  607.    in phrased in terms of MIB, this document allows alternative
  608.    mechanisms (e.g. configuration files) as well.
  609.  
  610.    The information required by a BIS that implements the IDRP for IP
  611.    protocol is:
  612.  
  613.       a) Location and identity of adjacent Intra-Domain ISs (routers)
  614.  
  615.          The MIB table INTRA-IS lists the IP addresses of the routers to
  616.          which the local BIS may deliver an inbound NPDU whose
  617.          destination lies within the BIS's routing domain.  These
  618.          routers listed in the INTRA-IS table support the intra-domain
  619.          routing protocol of this autonomous system, and share at least
  620.          one common subnet with the BIS.
  621.  
  622.  
  623. Expiration Date February 1994                          [Page 10]
  624.  
  625.  
  626. INTERNET DRAFT                                           September 1993
  627.  
  628.  
  629.          In particular, if the local BIS participates in both the
  630.          inter-domain routing protocol (IDRP) and the intra-domain
  631.          routing protocol, then the IP address of the local BIS will be
  632.          listed in the INTRA-IS table.
  633.  
  634.       b) Location and identity of BISs in the BIS's domain
  635.  
  636.          This information permits a BIS to identify all other BISs
  637.          located within its routing domain.  This information is
  638.          contained in the MIB table INTERNAL-BIS, which contains a set
  639.          of IP addresses which identify the BISs in the domain.
  640.  
  641.       c) Location and identity of BISs in adjacent domains:
  642.  
  643.          Each BIS needs information to identify the IP address of each
  644.          BIS located in an adjacent RD and reachable via a single
  645.          subnetwork hop.  This information is contained in the IDRP MIB
  646.          table EXTERNAL-BIS-NEIGHBORS, which is a table of IP addresses.
  647.  
  648.       d) IP network address information for all systems in the routing
  649.       domain
  650.  
  651.          This information is used by the BIS to construct its network
  652.          layer reachability information.  This information is contained
  653.          in the MIB table INTERNAL-SYSTEMS.  The IP network address
  654.          information shall be expressed in terms of IP address prefixes.
  655.          A single prefix can be used to describe:
  656.  
  657.  
  658.             - a host address,
  659.  
  660.             - a subnetwork number,
  661.  
  662.             - a network number, or
  663.  
  664.             - a collection of contiguous network numbers
  665.  
  666.       e) LOCAL RDI
  667.  
  668.          This information is contained in managed object LOCAL-RDI; it
  669.          is the RDI of the routing domain in which the BIS is located.
  670.          As specified in section 7 of this document, the RDI for an IDRP
  671.          for IP routing domain has an NSAP Address format.  This NSAP
  672.          Address format is built out of a fixed "header" and the
  673.          autonomous system number of this autonomous system (routing
  674.          domain).
  675.  
  676.       f) RIB-AttSet
  677.  
  678.          The RIB-AttSet contains information about the QoS functions a
  679.          BIS will support.  As described in section 4, this can be none,
  680.          any, or all of the Transit Delay, Residual Error, and Expense
  681.          distinguishing attributes.
  682.  
  683.  
  684. Expiration Date February 1994                          [Page 11]
  685.  
  686.  
  687. INTERNET DRAFT                                           September 1993
  688.  
  689.  
  690.       g) RDC-Config:
  691.  
  692.          This information identifies all the routing domain
  693.          confederations (RDCs) to which the RD of the local BIS belongs,
  694.          and it describes the nesting relationships that are in force
  695.          between them.  It is contained in the MIB table RDC-Config.
  696.  
  697.          Each RDC is identified by an RDI which has the format described
  698.          in section 7 of this document.
  699.  
  700.          Note that since a domain is not required to belong to a
  701.          confederation this information is optional and needs to be
  702.          present only at BISs of the domains that are part of one or
  703.          more of RDCs.
  704.  
  705.       h) Local IP addresses
  706.  
  707.          The LOCAL IP MIB table contains a list of IP addresses assigned
  708.          to the interfaces of a BIS. This information is used to
  709.          determine what interface should be used to forward outgoing
  710.          NPDUs.
  711.  
  712.  
  713. 5.2.9 Forwarding of IP packets
  714.  
  715.  
  716.    This section is intended to define the same function for IP packets
  717.    as is defined for CLNP packets in the "Forwarding Process for CLNS"
  718.    (Section 8 in [1]).
  719.  
  720.    It is assumed that a BIS is capable of distinguishing between a FIB
  721.    constructed by means of an intra-autonomous system routing protocol
  722.    and a FIB constructed by means of IDRP.
  723.  
  724.    After a BIS determines the packet's destination IP address, the BIS
  725.    shall proceed as follows:
  726.  
  727.  
  728.       a) If the destination address specifies a system located within
  729.       the autonomous system of the receiving BIS, then the BIS shall
  730.       forward the IP packet to any of the ISs listed in the managed
  731.       object INTRA-IS.  That is, any further forwarding of the IP packet
  732.       is the responsibility of the intra-autonomous system routing
  733.       protocol; otherwise,
  734.  
  735.       b) the destination system is located in a different autonomous
  736.       system, and the local BIS shall perform the following actions:
  737.  
  738.          It shall determine the IP-Derived distinguishing attribute,
  739.          according to clause 5.2.3.  It shall next apply the procedures
  740.          of clause 5.2.3 to determine if the IP-Derived distinguishing
  741.          attribute matches any of the RIB-Atts of the information
  742.          base(s) supported by the local BIS. If such a match is found,
  743.          then the FIB with the matched RIB-Atts is used for forwarding.
  744.  
  745.  
  746. Expiration Date February 1994                          [Page 12]
  747.  
  748.  
  749.  
  750.  
  751. INTERNET DRAFT                                           September 1993
  752.  
  753.  
  754.          If the procedures of clause 5.2.3 identify a non-default IP-
  755.          Derived distinguishing attribute, but the local BIS does not
  756.          maintain a FIB with the matching RIB-Atts, or the local BIS
  757.          maintains a FIB with the matching RIB-Atts but this FIB does
  758.          not have a route to the destination, then the local system sets
  759.          the Type Of Service field in the IP packet to 0 and uses the
  760.          FIB with no distinguishing attributes.
  761.  
  762.          The incoming IP packet shall be forwarded based on the FIB
  763.          entry that has the longest IP address prefix that matches the
  764.          destination of the incoming IP packet, as follows:
  765.  
  766.             1) If the entry in the inter-domain FIB that corresponds to
  767.             the destination address of an incoming IP packet contains a
  768.             NEXT_HOP that identifies an interface of a BIS such that the
  769.             interface is attached to a subnet shared with the local BIS,
  770.             then the IP packet shall be forwarded directly to the BIS
  771.             indicated in the NEXT_HOP entry over that interface;
  772.             otherwise,
  773.  
  774.             2) if the entry in the inter-domain FIB that corresponds to
  775.             the destination address of the incoming IP packet contains a
  776.             NEXT_HOP entry that identifies an interface of a BIS such
  777.             that the interface is not attached to any of the subnets
  778.             attached to the local BIS, then the local BIS has the
  779.             following options:
  780.  
  781.  
  782.                i) Encapsulate the IP packet
  783.  
  784.  
  785.                   The local BIS may encapsulate the IP packet, using its
  786.                   own IP address as the source address and the IP
  787.                   address of the next-hop BIS contained in the NEXT_HOP
  788.                   entry as the destination address. Since IP doesn't
  789.                   have a standard encapsulation protocol, use of this
  790.                   option should be discouraged.
  791.  
  792.  
  793.                ii) Use paths calculated by the intra-autonomous system
  794.                routing protocols
  795.  
  796.  
  797.                   The local BIS may query the FIB constructed by the
  798.                   intra-autonomous system routing protocols to ascertain
  799.                   if that FIB contains a route to the destination
  800.                   system. If that is the case, and if the path
  801.                   constructed by the intra-autonomous system routing
  802.                   protocols delivers the IP packet to the appropriate
  803.                   next-hop BIS, then the IP packet may be forwarded
  804.                   using the FIB constructed by the intra-autonomous
  805.                   system routing protocols.
  806.  
  807.  
  808.  
  809.  
  810. Expiration Date February 1994                          [Page 13]
  811.  
  812.  
  813.  
  814.  
  815. INTERNET DRAFT                                           September 1993
  816.  
  817.  
  818.    ITEM       Questions/Features             Refer. Status Support
  819.  
  820.    ----------------------------------------------------------------
  821.  
  822.    IP_EXTFWD  Does the BIS correctly forward 5.3    M      Yes___
  823.  
  824.               IP packets with destinations
  825.  
  826.               outside its routing domain?
  827.  
  828.    IP_INTFWD  Does the BIS correctly forward 5.3    M      Yes___
  829.  
  830.               IP packets with destinations
  831.  
  832.               inside its routing domain?  ---------
  833.    ------------------------------------------------------
  834.  
  835.    Table 1: PICS Proforma for IDRP: IP packet forwarding
  836.  
  837.  
  838.    The "ITEM" column describes the feature in the IP forwarding function
  839.    that the IDRP implementation is to provide.  The "Question/Feature"
  840.    section seeks to describe the feature.  The Reference is the section
  841.    in this document that describes this feature.  The status gives an
  842.    indication of "M" - Mandatory feature for an IDRP implementation or
  843.    "O" - optional feature.  The "Support" column is a column for the
  844.    implementor to check whether this feature is available in a
  845.    particular implementation.)
  846.  
  847.  
  848. 5.3 Advertising NLRI information for IP addresses
  849.  
  850.  
  851.    The NLRI field in an UPDATE PDU contains IP address information about
  852.    systems that reside within a given routing domain or whose IP address
  853.    space is under the control of the administrator of the routing
  854.    domain. It should not be used to convey information about the
  855.    operational status of these systems. The information in the NLRI
  856.    field is intended to convey static administrative information rather
  857.    than dynamic transient information; for example, it is not necessary
  858.    to report that a given system has changed from offline to online.
  859.  
  860.    End systems (hosts) and Intermediate systems (routers) within a RD
  861.    using IDRP may use any IP address that is valid within the IP
  862.    context.  Within the NLRI, the address information for a set of IP
  863.    addresses may be represented by an IP prefix.  An IP prefix is the
  864.    sequence of bits in a 4 byte IP address which are common between a
  865.    set of IP addresses.
  866.  
  867.    For example, the addresses 192.5.0.0 through 192.5.255.255 have the
  868.    first 16 bits of the address information in common.  These 16 bits of
  869.    the IP address may be called an IP prefix which represents the set of
  870.    IP addresses 192.5.0.0 through 192.5.255.255.
  871.  
  872.  
  873.  
  874. Expiration Date February 1994                          [Page 14]
  875.  
  876.  
  877.  
  878. INTERNET DRAFT                                           September 1993
  879.  
  880.  
  881.    An IP prefix must contain a contiguous set of bits starting at the
  882.    most significant bit, but the bits may cover any part of the 4 byte
  883.    IP address. The following guidelines for inclusion of IP address
  884.    prefixes in the NLRI field of the UPDATE PDUs originated within a
  885.    routing domain will provide efficient use of this protocol:
  886.  
  887.       a) Only IP prefixes representing IP addresses that are within the
  888.       control of the administrator of a given routing domain may be
  889.       reported in the NLRI field for a RD.  These IP prefixes can
  890.       represent IP addresses for systems which are:
  891.  
  892.          - online,
  893.  
  894.          - offline, or
  895.  
  896.          - allocated to the network, but not yet allocated to a machine.
  897.  
  898.  
  899.       b) IP prefixes representing IP addresses outside of the RD
  900.       administrator's control shall not be included in the NLRI.
  901.  
  902.       c) For efficient use of the protocol, the WITHDRAW ROUTES field
  903.       should not be used to report the NLRI of systems that are offline.
  904.       This field should be used only to advertise IP prefixes for IP
  905.       addresses that are no longer under the control of the
  906.       administrator of the local routing domain, regardless of whether
  907.       the systems are online or offline.
  908.  
  909.  
  910.    A conformant implementation is required to have the ability to
  911.    specify when an aggregated route may be generated out of partial
  912.    routing information. A BIS at the border of an autonomous system (or
  913.    group of autonomous systems) must be able to generate an aggregated
  914.    route for a whole set of NLRIs over which is has administrative
  915.    control, even when not all of them are reachable at the same time.
  916.  
  917.  
  918.  
  919.  
  920. 6  Determining the forwarding address (Next Hop)
  921.  
  922.  
  923.    NEXT_HOP information associated with a particular route shall be
  924.    derived from the NEXT_HOP attribute in the UPDATE BISPDU that carries
  925.    the route. If that attribute is not present, it shall be derived from
  926.    the source IP address of the IP packet that carries the UPDATE BISPDU
  927.    containing the route.
  928.  
  929.  
  930. 7  Routing Domain Identifiers used for both IP and OSI
  931.  
  932.  
  933.    Routing Domain Identifiers (RDIs) are identifiers used in BISPDUs to
  934.    uniquely identify individual routing domains and routing domain
  935.  
  936.  
  937. Expiration Date February 1994                          [Page 15]
  938.  
  939.  
  940.  
  941. INTERNET DRAFT                                           September 1993
  942.  
  943.  
  944.    confederations.
  945.  
  946.    For ease of administration, the RDI is taken out of the NSAP address
  947.    space.  However, the RDI is just a number which identifies the
  948.    routing domain, and need not bear any relationship to any reachable
  949.    addresses within the domain.
  950.  
  951.    For ease of interworking with other IP inter-autonomous system
  952.    routing protocols, The RDI used for an autonomous system running IDRP
  953.    for IP should be derived from an appropriately assigned Autonomous
  954.    System Number as follows:
  955.  
  956.  
  957.       47:00:05:c0:01:aa:aa
  958.  
  959.       Where 47:00:05:c0:01 is a unique prefix assigned by a valid
  960.       addressing authority (NIST), and aa:aa is the autonomous system
  961.       number.
  962.  
  963.  
  964.    This encoding of the RDI contains a "fixed header" (the
  965.    47:00:05:c0:01 sequence) plus the AS value.
  966.  
  967.    (Note: While AS values are currently 2 octets long, IDRP allows
  968.    Routing Domain Identifiers to be of arbitrary length. Thus, if the
  969.    space of AS numbers is expanded to be greater than two octets, this
  970.    may be accommodated by simply lengthening the above encoding--the AS
  971.    number following the fixed header is considered to be right
  972.    justified, and its size can be unambiguously determined from the RDI
  973.    length.)
  974.  
  975.  
  976. 8 Deployment Guidelines for IDRP for IP
  977.  
  978.  
  979.    The correct and efficient operation of the IDRP protocol requires
  980.    that certain guidelines are used for deployment with ISO routing
  981.    Domains. Some equivalent deployment guidelines for IDRP for IP are
  982.    required within Autonomous Systems. These guidelines represent only
  983.    the required deployment guidelines, and not details on the usage of
  984.    IDRP for IP in the Internet.
  985.  
  986.  
  987.  
  988. 8.1 Minimum configuration of an Autonomous System
  989.  
  990.  
  991.    An autonomous system using IDRP for IP must as a minimum contain:
  992.  
  993.    one BIS, and one BIS capable of delivering NPDUs to the intra-domain
  994.    routing function if the AS contains hosts.
  995.  
  996.  
  997.  
  998.  
  999.  
  1000. Expiration Date February 1994                          [Page 16]
  1001.  
  1002.  
  1003.  
  1004. INTERNET DRAFT                                           September 1993
  1005.  
  1006.  
  1007. 8.2 Multiple IDRP sessions between the same pair of routers
  1008.  
  1009.  
  1010.    An IP router may have multiple IP addresses, one for each interface.
  1011.    In contrast, an OSI Intermediate System has only one Network Entity
  1012.    Title (network address). An OSI BIS thus may not have multiple IDRP
  1013.    sessions with another BIS, since the NET is unique and there is no
  1014.    mechanism for multiplexing sessions. However, an IP router may
  1015.    potentially have multiple IDRP sessions with another router, since
  1016.    each BIS may have multiple IP addresses, and one BIS may not be able
  1017.    to ascertain that those addresses correspond to the same BIS.
  1018.    Multiple IDRP sessions between IP BISs may not be efficient, but they
  1019.    are not illegal, nor do they impact the robustness of the IDRP for IP
  1020.    protocol; they will simply appear as multiple paths to the same
  1021.    neighboring AS. One possible way of avoiding multiple parallel IDRP
  1022.    sessions between a pair of BISs within a single autonomous system is
  1023.    to bind all source addresses of outgoing BISPDUs to the IP address of
  1024.    a particular interface of the BIS. Likewise, for a pair of BISs
  1025.    located in adjacent autonomous systems, binding the source addresses
  1026.    to a single address of an interface attached to a common subnetwork
  1027.    provides for the elimination of multiple parallel sessions.
  1028.  
  1029. 9. Recommended set of supported routing policies.
  1030.  
  1031.  
  1032.    Policies are provided to IDRP in the form of configuration
  1033.    information.  This information is not directly encoded in the
  1034.    protocol. Therefore, IDRP can provide support for very complex
  1035.    routing policies (an example of such policy is presented in Annex K
  1036.    of [1]). However, it is not required that all IDRP implementations
  1037.    support such policies.
  1038.  
  1039.    We are not attempting to standardize the routing policies that must
  1040.    be supported in every IDRP implementation, but we strongly encourage
  1041.    all implementors to support the following set of routing policies:
  1042.  
  1043.    IDRP implementations should allow an AS to control announcements of
  1044.    IDRP-learned routes to adjacent AS's.  Implementations should also
  1045.    support such control with at least the granularity of a single
  1046.    network.  Implementations should also support such control with the
  1047.    granularity of an autonomous system, where the autonomous system may
  1048.    be either the autonomous system that originated the route, or the
  1049.    autonomous system that advertised the route to the local system
  1050.    (adjacent autonomous system).  Care must be taken when a BIS selects
  1051.    a new route that can't be announced to a particular external peer,
  1052.    while the previously selected route was announced to that peer.
  1053.    Specifically, the local system must explicitly indicate to the peer
  1054.    that the previous route is now infeasible.  IDRP implementations
  1055.    should allow an AS to prefer a particular path to a destination when
  1056.    more than one path is available.  This function may be implemented by
  1057.    allowing system administrators to assign "weights" to AS's and having
  1058.    the route selection process select a route with the lowest "weight"
  1059.    (where "weight" of a route is defined as a sum of "weights" of all
  1060.    AS's in the RD_PATH path attribute associated with that route).  IDRP
  1061.  
  1062.  
  1063. Expiration Date February 1994                          [Page 17]
  1064.  
  1065.  
  1066.  
  1067. INTERNET DRAFT                                           September 1993
  1068.  
  1069.  
  1070.    implementations should allow an AS to ignore routes with certain AS's
  1071.    in the RD_PATH path attribute.  Such function can be implemented by
  1072.    using the technique outlined in [9], and by assigning "infinity" as
  1073.    "weights" for such AS's. The route selection process must ignore
  1074.    routes that have "weight" equal to "infinity".
  1075.  
  1076.  
  1077. 10. Security Considerations
  1078.  
  1079.  
  1080.    Security issues are not discussed in this document.
  1081.  
  1082.  
  1083. 11. Acknowledgements
  1084.  
  1085.  
  1086.    A large set of thanks to Dave Katz (cisco) who helped edit the
  1087.    document.  We would also like to express my thanks to Scott Brim
  1088.    (Cornell University) for his review and constructive comments.
  1089.  
  1090.    The authors would like to acknowledge contributions made by authors
  1091.    of [8], Yakov Rekhter and Phill Gross.  Certain sections of this
  1092.    document are taken (sometimes almost verbatim) from their document.
  1093.  
  1094.  
  1095. 12. References
  1096.  
  1097.  
  1098.    [1]   ISO/IEC IS 10747 - Information Processing Systems -
  1099.    Telecommunications and Information Exchange between Systems -
  1100.    Protocol for Exchange of Inter-domain Routeing Information among
  1101.    Intermediate Systems to Support Forwarding of ISO 8473 PDUs, 1993.
  1102.  
  1103.    [2]   ISO 8473 - Information Processing Systems - Data Communications
  1104.    - Protocol for Providing the Connectionless-mode Network Service,
  1105.    1988.
  1106.  
  1107.    [3]   ISO/IEC 10589 - Information Processing Systems -
  1108.    Telecommunications and Information Exchange between systems -
  1109.    Intermediate System to Intermediate System Intra-Domain routeing
  1110.    information exchange protocol for use in conjunction with the
  1111.    Protocol for providing the Connectionless-mode Network Service (ISO
  1112.    8473), 1992.
  1113.  
  1114.    [4]   ISO 9542 - Information Processing Systems - Telecommunications
  1115.    and information exchange between systems - End system to Intermediate
  1116.    system routeing exchange protocol for use in conjunction with the
  1117.    Protocol for providing the connectionless-mode network service (ISO
  1118.    8473)
  1119.  
  1120.    [5]   RFC 791 (Jon Postel, editor) - Internet Protocol - DARPA
  1121.    Internet Program Protocol Specification (September 1981)
  1122.  
  1123.    [6]   Hares, S., "Definition of Managed Objects for the IDRP for IP",
  1124.  
  1125.  
  1126.  
  1127. Expiration Date February 1994                          [Page 18]
  1128.  
  1129.  
  1130.  
  1131. INTERNET DRAFT                                           September 1993
  1132.  
  1133.  
  1134.    Internet Draft, March 1993
  1135.  
  1136.    [7]  Fuller, V., Li, T., Yu, J, and Varadhan, K., "Supernetting: an
  1137.    Address Assignment and Aggregation Strategy", RFC1519, September 1993
  1138.  
  1139.    [8] Rekhter, Y., Gross, P., "Application of the Border Gateway
  1140.    Protocol in the Internet", Internet Draft September 1992
  1141.  
  1142.    [9] Braun, H-W., "Models of Policy Based Routing", RFC 1104,
  1143.    Merit/NSFNET, June 1989.
  1144.  
  1145.    [10] Rekhter, Y., Li, T., "An Architecture for IP Address Allocation
  1146.    with CIDR", RFC1518, September 1993
  1147.  
  1148.    [11] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4),
  1149.    Internet Draft, cisco Systems, T.J. Watson Research Center, IBM
  1150.    Corp., September 1992.
  1151.  
  1152.    [12] Almquist, P., "Type of Service Routing in the Internet Protocol
  1153.    Suite", RFC 1248, July 1992.
  1154.  
  1155.  
  1156. Authors' Addresses
  1157.  
  1158.  
  1159.  
  1160.    Susan Hares
  1161.    Merit, Inc
  1162.    1071 Beal Avenue
  1163.    Ann Arbor, MI 4810x
  1164.  
  1165.    Phone: (313) 936-2095
  1166.    Email: skh@merit.edu
  1167.  
  1168.    John Scudder
  1169.    Merit, Inc
  1170.    1071 Beal Avenue
  1171.    Ann Arbor, MI 4810x
  1172.  
  1173.    Phone: (313) 764-5384
  1174.    Email: jgs@merit.edu
  1175.  
  1176.  
  1177.    IETF IDRP for IP WG mailing list: idrp-for-ip@merit.edu
  1178.    To be added: idrp-request@merit.edu
  1179.  
  1180.  
  1181.  
  1182.  
  1183.  
  1184.  
  1185.  
  1186.  
  1187.  
  1188.  
  1189. Expiration Date February 1994                          [Page 19]
  1190.  
  1191.  
  1192.